home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000095_owner-urn-ietf _Sat Mar 29 16:38:45 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  7KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id QAA27888
  3.     for urn-ietf-out; Sat, 29 Mar 1997 16:38:45 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id QAA27879
  6.     for <urn-ietf@services.bunyip.com>; Sat, 29 Mar 1997 16:38:41 -0500 (EST)
  7. Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA23900  (mail destined for urn-ietf@services.bunyip.com); Sat, 29 Mar 97 16:38:37 -0500
  9. Received: from montana (transitory6.lanl.gov [128.165.7.194]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id OAA15167; Sat, 29 Mar 1997 14:38:32 -0700 (MST)
  10. Message-Id: <3.0.32.19970329143723.0096ca00@acl.lanl.gov>
  11. X-Sender: rdaniel@acl.lanl.gov
  12. X-Mailer: Windows Eudora Pro Version 3.0 (32)
  13. Date: Sat, 29 Mar 1997 14:37:33 -0700
  14. To: Dan Connolly <connolly@w3.org>
  15. From: "Ron Daniel, Jr." <rdaniel@acl.lanl.gov>
  16. Subject: [URN] Relative URNs considered harmful
  17. Cc: urn-ietf@bunyip.com
  18. Mime-Version: 1.0
  19. Content-Type: text/plain; charset="us-ascii"
  20. Sender: owner-urn-ietf@Bunyip.Com
  21. Precedence: bulk
  22. Reply-To: "Ron Daniel, Jr." <rdaniel@acl.lanl.gov>
  23. Errors-To: owner-urn-ietf@Bunyip.Com
  24.  
  25. At 01:58 PM 3/28/97 -0600, Dan Connolly wrote:
  26. >But do you see the technical benefits of exploiting the
  27. >URI hierarchy syntax? It allows the use of relative
  28. >URLs. It remains to be seen whether they would be used
  29. >in the ISBN context as much as they are in the http:
  30. >and ftp: contexts. But the technical benefit is there.
  31.  
  32. Awhile back this group started to discuss relative URNs.
  33. Although that discussion has peetered out, no conclusion
  34. was reached. Now that the various people have had a chance
  35. take a breath and regroup their arguments, I'll take
  36. Dan Connolly's message as a springboard to resume them.
  37. Perhaps we will come to consensus on the point and settle it.
  38.  
  39. During the earlier set of discussions my view on relative
  40. URNs changed from "unnecessary but probably harmless" to
  41. "unnecessary and probably harmful". Let me explain why.
  42.  
  43. Unnecessary:
  44. This is not the key point of controversy, but let me dispose of
  45. it quickly.
  46.  
  47. Relative URLs came about for two reasons. The first was concision,
  48. a reasonable consideration since we were all creating HTML my hand
  49. using our editors. (Many of us still do, so this point has some
  50. weight). The second reason was to make it easier to move connected
  51. sets of resources from one site to another. If the links were relative,
  52. there was less patching to do.
  53.  
  54. Since URNs are defined to be location independent, it is not the
  55. documents that need to be edited if we want to move a bunch of
  56. resources from one location to another. Therefore, the most important
  57. reason for relative URLs does not apply to URNs.
  58.  
  59. Probably Harmful:
  60. This will be more contentious, but here goes. This argument depends
  61. on an observation:
  62.  
  63. Observation - a resource may have more than one URN.
  64. We have used the weather map as one example of a resource having, at
  65. least temporarily, two URNs. Another example is more telling. Pick
  66. a recently-published book from your shelf. Chances are excellent that
  67. it will have at least two, and probably three, separate identifiers.
  68. The first book I've grabbed is "The Tailor of Panama" by Le Carre. (Ok,
  69. sue me for my reading tastes).  It has the identifiers:
  70.    ISBN  0-679-45446-2
  71.    UPC   9 780679 454465  
  72.    LC    96-34802
  73.  
  74. Essentially all books currently pulished will have the first two.
  75. The last is the Lib. Congress Card Number. As part of the "Cataloging
  76. in Publication" effort, many books will be printed with the third.
  77. (Look on the title page of the book you grabbed to see if has "CIP"
  78. on it somewhere. That's the Cataloging In Publication stuff.)
  79.  
  80. All of these identifiers are reasonable candidates for URN namespaces.
  81. If we were to follow Dan's suggestion of using "/" for hierarchy,
  82. (and our already-agreed upon use of "urn:") we would have
  83.     urn:isbn:0/679/45446/2
  84.     urn:upc:9/780679/454465  
  85.     urn:lc:96/34802
  86.  
  87. The problem with relative URNs is that there is no consistent hierarchy
  88. across all identification schemes. Assuming Le Carre's work referred
  89. to another using the relative identifier "4", what does that mean?
  90. Is it
  91.     urn:isbn:0/679/45446/4    // An illegal ISBN since we have only
  92.                               // munged the check character.
  93.     urn:upc:9/780679/4        // This might work, except that once again
  94.                               // the check character has probably been munged.
  95.                               // I haven't read the UPC rules lately, I think
  96.                               // the initial "9" is the check character.
  97.     urn:lc:96/4               // this might work
  98.  
  99. Other possibilities are to take the URL that was used to fetch the resource
  100. (assuming there was one) and use the relative identifier "4" in conjunction
  101. with it.
  102.  
  103. The difficulty of correctly dealing with check characters is only one
  104. of the problems with relative URNs. The big point is that there is no
  105. uniform hierarchy across all namespaces, and without one it is unsafe
  106. to do relative URI processing. We have to know the original identifier the
  107. new one is relative to.
  108.  
  109. The last time we took up this topic, Dan LaLiberte presented the very
  110. nice set of rules that are used in relative URL processing to answer
  111. this question. Lets go through those and see if they apply to URNs.
  112.  
  113. From: Daniel LaLiberte 
  114. Date: Fri, 31 Jan 1997 16:34:21 -0600 (CST)
  115. >... finding the base URI ...
  116. >Use the first one that succeeds:
  117. >
  118. >1. Use the explicit base URI from the document content, if any.
  119. >2. Use the explicit base URI from the encapsulating entity, if any.
  120. >   (e.g. http response message, another document, etc)
  121. >3. Use the URI used to retrieve the entity, if any.
  122. >4. Otherwise the base URI is undefined.
  123. >
  124. >Step 3 should be clarified: If there is no explicit base URI
  125. >found by step 1 and 2, we should use the *last* URI used
  126. >to retrieve the entity, not the first or some intermediate.  This
  127. >applies both for a chain of URL redirections or for a URN that is
  128. >resolved into a URL.  Roy Fielding pointed this out to me when I
  129. >thought it should be the first URI used, or perhaps the last
  130. >permanent redirect.
  131.  
  132. Step one seems dodgy for our example, we have the equivalent of three
  133. BASE tags. (Don't tell me there should be only one, the book was printed
  134. with three.)
  135.  
  136. Steps 2 and 3 suffer from the same problem. Over long time scales, there is
  137. no telling what sort of URI will be used to fetch the thing. Assuming
  138. that it will have the same hierarchy as the original seems dangerous.
  139.  
  140.  
  141. Ron Daniel Jr.              voice:+1 505 665 0597
  142. Advanced Computing Lab        fax:+1 505 665 4939
  143. MS B287                     email:rdaniel@lanl.gov
  144. Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
  145. Los Alamos, NM, USA, 87545